%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%				CONFIGURAZIONE DEL DOCUMENTO (NON MODIFICARE)			%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\documentclass[a4paper,11ptn]{report}                                   %
\usepackage[italian]{babel}                                             %
\usepackage{graphicx}                                                   %
\usepackage[colorlinks=true]{hyperref}                                  %
\usepackage{url}                                                        %
\usepackage{eurosym}                                                    %
\usepackage{lastpage}                                                   %
\usepackage{fancyhdr}                                                   %
\usepackage[utf8]{inputenc}                                             %
\hypersetup{linkbordercolor=1 1 1}                                      %
\hypersetup{urlcolor=blue}                                              %
\hypersetup{linkcolor=black}                                            %
\graphicspath{{../immagini/}}                                           %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% 		COMPLETARE I CAMPI VUOTI PER LA GENERAZIONE AUTOMATICA			%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\newcommand{\Documento}{Piano di Qualifica}                             % nome del documento
\newcommand{\Sommario}{
Lo scopo del presente documento \`e quello di informare il committente riguardo le strategie di validazione e verifica che la SevenSoft applicher\`a al prodotto SiFiSy.}           % sommario
\newcommand{\CodiceRevisione}{RQ}                                      % revisione (es. RPP)
\newcommand{\DataCreazione}{29 Novembre 2009}                           % data di creazione
\newcommand{\Versione}{2.2}                                             % versione attuale
\newcommand{\StatoDocumento}{Formale, Esterno}                          % stato (es. Formale, Interno)
\newcommand{\Redazione}{Samuele Faggian}                                    % autore del documento
\newcommand{\Revisione}{Luca Zanini}                                 % verificatore del documento
\newcommand{\Approvazione}{Alessandro Vedovato}                              % chi approva (responsabile)
\newcommand{\Committente}{Prof. Tullio Vardanega, Prof. Renato Conte}   % committente/i
\newcommand{\Proponente}{Dott. Claudio Palazzi}                         % proponente/i
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% 			IMPOSTAZIONE DEL DOCUMENTO (NON MODIFICARE)					%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\fancypagestyle{plain}{                                                 %
\fancyhf{}                                                              %
\fancyhead[L]{\Documento\ \Versione\ - \CodiceRevisione}                            %
\fancyfoot[C]{\thepage}                                                 %
\fancyhead[R]{\includegraphics[scale=0.3]{logoSevenSoft.png}}           %
}                                                                       %
\begin{document}                                                        %
\pagenumbering{Roman}                                                   %
\begin{center}                                                          %
\includegraphics[scale=0.8]{logoSevenSoft.png}\\                        %
\vspace*{1in}                                                           %
\huge{\textbf{\textbf{\Documento}}}\\                                   %
\vspace*{2cm}                                                           %
Versione: \Versione\\                                                   %
\vspace*{3cm}                                                           %
\vspace*{0.5in}                                                         %
\textbf{Sommario}\\                                                     %
\end{center}                                                            %
\begin{normalsize}                                                      %
\Sommario                                                               %
\end{normalsize}                                                        %
%\end{center}                                                           %
\newpage                                                                %
\thispagestyle{plain}                                                   %
\vspace*{0.5in}                                                         %
\begin{center}                                                          %
\begin{tabular}{l}                                                      %
\Large{\textbf{Capitolato: Simulatore File System}}\\                   %
\begin{tabular}{|p{5cm}|p{7cm}|}                                        %
\hline                                                                  %
\textbf{Data creazione:} & \DataCreazione\\                             %
\hline                                                                  %
\textbf{Versione:} & \Versione\\                                        %
\hline                                                                  %
\textbf{Stato del documento:} & \StatoDocumento\\                       %
\hline                                                                  %
\textbf{Redazione:} & \Redazione\\                                      %
\hline                                                                  %
\textbf{Revisione:} & \Revisione \\                                     %
\hline                                                                  %
\textbf{Approvazione:}  & \Approvazione\\                               %
\hline                                                                  %
\textbf{Committente:} & \Committente \\                                 %
\hline                                                                  %
\textbf{Proponente:} & \Proponente \\                                   %
\hline                                                                  %
\end{tabular}\\                                                         %
\end{tabular}                                                           %
\end{center}                                                            %

\newpage
\thispagestyle{plain}
\begin{center}
\begin{tabular} {l}
\Large{\textbf{Legenda Diario delle modifiche}}\\
\begin{tabular}{|p{3cm}|p{7cm}|}
\hline
Vers & Versione del documento \\
\hline
Verif & Verificatore del documento \\
\hline
Resp & Responsabile che approva il documento \\
\hline
\hline
GB & Giuseppe Biolo \\
\hline
DDM & Daniele De Matteo \\
\hline
SF & Samuele Faggian \\
\hline
GF & Giuseppe Ferri \\
\hline
AL & Alberto Longato \\
\hline
AV & Alessandro Vedovato \\
\hline
LZ & Luca Zanini \\
\hline                                                                  %
\end{tabular} \\                                                        %
\end{tabular}                                                           %
\end{center}

\vspace*{2cm}                                                          %

\begin{center}                                                          %
\begin{tabular}{l}                                                      %
\Large{\textbf{Diario delle modifiche}}\\                               %
\begin{tabular}{|p{0.7cm}|p{1.9cm}|p{1.2cm}|p{1cm}|p{1cm}|p{6.9cm}|}     %
\hline                                                                  %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% 		COMPLETARE I CAMPI VUOTI PER IL DIARIO DELLE MODIFICHE			%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\textbf{Vers} & \textbf{Data} & \textbf{Autore} & \textbf{Verif} & \textbf{Resp} & \textbf{Descrizione} \\%
\hline
2.5 & 06/06/2010 & VA & SF & LZ& Aggiunti esempi test, integrato plug-in emma\\
\hline
2.4 & 10/05/2010 & VA & SF & LZ& Modifiche metriche copertura test\\
\hline
2.3 & 15/04/2010 & LA & LZ & AV & Modifiche varie revisioni, inizio stesura strumenti per il test\\
\hline
2.2 & 07/03/2010 & DDM& LZ& AV& Integrazione e ampliamento metriche di codice e verifica documenti, resoconto attivit\`a di verifica\\
\hline
2.1 & 07/02/2010 & DDM& LZ& AL& Correzioni varie particolarmente curati i punti toccati nella valutazione dell'RPP\\
\hline
2.0 & 22/01/2010 &GB& DDM & AL& Ulteriore integrazione del contenuto e correzioni\\
\hline
1.0 & 20/01/2010 &GB& DDM & GF& Rivedute e incrementate alcune sezioni\\
\hline
1.0 & 15/01/2010 &GB& DDM & GF& Correzione errori ortografici e approfondimento di alcune sezioni\\
\hline
0.4 & 08/12/2009 &LZ& GB& DDM& Addattamento a modello unico e completamento documento\\
\hline
0.4 & 08/12/2009 &LZ& GB& DDM& Addattamento a modello unico e completamento documento\\
\hline
0.3 & 06/12/2009 &LZ& GB& DDM& Correzioni ortografiche varie\\
\hline
0.2 & 30/11/2009 &AL& GB& DDM& Integrazione con punti successivi e correzioni\\
\hline
0.1 & 29/11/2009 &LZ& GB& DDM& Prima stesura documento\\
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% 			IMPOSTAZIONE DEL DOCUMENTO (NON MODIFICARE)					%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\hline                                                                  %
\end{tabular} \\                                                        %
\end{tabular}                                                           %
\end{center}                                                            %
\newpage                                                                %
\tableofcontents                                                        %
\newpage                                                                %
\pagenumbering{arabic}                                                  %
\fancypagestyle{plain}{                                                 %
\fancyhf{}                                                              %
\fancyhead[L]{\Documento\ \Versione\ - \CodiceRevisione}                            %
\fancyfoot[C]{\thepage\ di \pageref{LastPage}}                          %
\fancyhead[R]{\includegraphics[scale=0.3]{logoSevenSoft.png}}           %
}                                                                       %
\pagestyle{plain}                                                       %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%	COMPLETARE I CAMPI VUOTI PER IL TESTO DEL DOCUMENTO (VEDI NORME)	%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% Capitolo 1 - INTRODUZIONE AL DOCUMENTO
\chapter{Introduzione}

\section{Scopo del documento}
Il presente documento si propone di fornire definizioni e strategie di pianificazione delle procedure che il team SevenSoft adotter\`a per garantire la qualit\`a del prodotto denominato SiFiSy.\\
Il Piano di Qualifica \`e il prodotto dell'attivit\`a di Verifica e Validazione che SevenSoft ha intenzione di mettere in atto come descritto nello standard ISO/IEC 12207:1995. Tali attivit\`a verranno applicate a tutti i processi di ciclo di vita del prodotto software. Il Piano di Qualifica verr\`a aggiornato regolarmente durante tutte le fasi di sviluppo, in modo da adeguarsi alle scelte progettuali, ad eventuali variazioni dei requisiti e/o richieste in fase di revisione da parte del committente.\\
Per garantire un adeguato livello qualitativo \`e necessario il rispetto delle specifiche definite in fase di analisi di progetto.\\
La versione iniziale di questo documento ha valore contrattuale per la gara d'appalto; il documento verr\`a di seguito incrementato (ad es. includendo gli eventuali test) e le prossime versioni avranno valore contrattuale solo dopo l'approvazione del committente.

\section{Scopo del prodotto}
SiFiSy \`e  un simulatore di \underline{FS} che ha come obiettivo quello di mostrare agli studenti, ma in generale a qualunque utente interessato, il funzionamento e la logica di implementazione di diversi \underline{FS}, con la possibilit\`a  di confrontare le varie configurazioni scelte e condurre alcune analisi significative.\\
Per ulteriori informazioni riguardanti scopi e funzionalit\`a del prodotto si prega di fare riferimento al documento \textit{Analisi dei Requisiti.pdf}.

\section{Glossario}
Il glossario viene fornito in un documento separato denominato \textit{glossario.pdf} che raccoglie le definizioni, acronimi ed abbreviazioni di tutta la documentazione. I termini presenti nel glossario verranno marcati nel documento con una sottolineatura.

\section{Riferimenti}
\subsection{Riferimenti normativi}
\begin{itemize}
\item{Std IEEE 1008-1987 - Standard for Software Unit Testing}
\item{Std AS/NZS ISO/IEC 12207:1997 Software life cycle processes}
\item{normeDiProgetto-2.1.pdf}
\end{itemize}
\subsection{Riferimenti informativi}
\begin{itemize}
\item {Ian Sommerville, Software Engineering, Addison Wesley, 8a edizione (04 Giugno 2006).\\
	ISBN: 978-0321313799}
\item {Guide to the SWEBOK:\\
\url{http://www.swebok.org}}
\item {Assembla Home Page\\
\url{http://www.assembla.com}}
\item {Subversion \\
\url{http://subversion.tigris.org}}
\end{itemize}

% Capitolo 2 - VISIONE GENERALE DELLA STRATEGIA DI VERIFICA
\chapter{Visione generale della strategia di verifica}

\section{Organizzazione, pianificazione strategica e temporale, responsabilit\`a}
Le responsabilit\`a verso il cliente sulle attivit\`a di verifica sono a carico del Responsabile di progetto.\\
Durante la realizzazione del prodotto, il responsabile interno dell'attivit\`a di verifica \`e il Verificatore. In particolare, viene nominato un responsabile tra tutti i Verificatori attivi durante la fase, con il compito di coordinare le verifiche e di redigere un resoconto riassuntivo dei controlli eseguiti. Tali resoconti saranno allegati al presente documento nell'apposita sezione e saranno necessari al Responsabile di progetto per verificare la completezza dei documenti, la copertura dei test, ecc.\\
La natura del modello a cascata, scelto da SevenSoft per lo sviluppo del progetto, impone alcune regole e strategie di verifica che verranno qui di seguito descritte.\\
Le attivit\`a di verifica cominciano approssimativamente in un periodo compreso tra l'inizio e la met\`a di una fase o appena esiste un prodotto organizzato, su cui quindi abbia senso fare qualsiasi tipo di verifica.\\
Le attivit\`a di verifica sono pianificate in base alle varie fasi di realizzazione del progetto e sono elencate di seguito.
\subsection{Fase di analisi dei requisiti}
Durante la fase di analisi dei requisiti, l'attivit\`a di verifica inizia nel momento in cui gli Analisti presentano una prima stesura del documento, contenente i requisiti pi\`u immediati definiti con una prima analisi del capitolato.\\
Il lavoro dei Verificatori consiste nel controllare tale documento e nel comunicare agli Analisti se vi sono errori tipografici e dattilografici; inoltre dovranno assicurarsi che il contenuto del documento e delle rispettive sezioni siano coerenti con l'argomento trattato e verificare che non siano presenti requisiti ridondanti, superflui o in conflitto tra di loro.\\
Nel caso fossero presenti errori nella stesura dei requisiti il lavoro degli Analisti potrebbe quindi ripetersi finch\`e il processo di verifica non avr\`a esito positivo. Il processo di analisi e quello di verifica procedono quindi con un certo grado di parallelismo.\\
Una volta terminato il lavoro degli Analisti, il documento finale sar\`a revisionato dai Verificatori e, se approvato dal Responsabile di progetto, sar\`a  consegnato al proponente per permettergli di valutare l'offerta della SevenSoft riguardo al prodotto richiesto.\\
Il contenuto del documento sar\`a in parte negoziabile col proponente, ovvero eventuali requisiti aggiuntivi, provenienti dal proponente stesso o dal fornitore, saranno oggetto di analisi per verificarne la fattibilit\`a. In questo modo, se l'offerta venisse accettata, il lavoro degli Analisti, e di conseguenza quello dei Verificatori, potrebbe ancora ripetersi per la definizione dei nuovi requisiti che eventualmente dovessero emergere dalla discussione con il proponente e per la verifica della documentazione annessa.\\
Le attivit\`a di verifica in questa prima fase saranno principalmente rivolte alla correttezza della forma e dei contenuti del documento di Analisi dei Requisiti.\\
\subsection{Fase di progettazione}
Durante la fase di progettazione, saranno eseguite principalmente due fasi di verifica:
\begin{itemize}
\item Al termine della progettazione architetturale \`e compito dei Verificatori stabilire se la progettazione fatta soddisfa i requisiti attesi dal committente (prova di copertura);
\item L'accettazione della progettazione architetturale d\`a il via ai Progettisti per cominciare il processo di progettazione di dettaglio, che dovr\`a essere fedele alla progettazione architetturale approvata.\\
In questa seconda fase il lavoro di Verificatori e Progettisti pu\`o, ancora una volta, procedere con un certo grado di parallelismo, attivando il processo di verifica ogni qualvolta sia necessario valutare la correttezza del risultato di un processo di progettazione.\\
Cos\`i facendo sar\`a pi\`u facile garantire la correttezza di ogni singola parte progettata e alla fine baster\`a controllare che l'aggregazione di tutte le parti, precedentemente controllate e approvate, non sia fonte di errore.
\end{itemize}
\subsection{Fase di realizzazione}
Alla fine della fase di realizzazione saranno eseguiti test dinamici:
\begin{itemize}
\item Questi test di verifica avranno il compito di dimostrare l'affidabilit\`a e il funzionamento corretto del prodotto.
\item I test saranno eseguiti inizialmente sulle singole unit\`a del prodotto (test di unit\`a), poi sull'aggregazione di pi\`u unit\`a fra loro (test di integrazione) e infine sul prodotto nel suo insieme (test di sistema).\\
Per eseguire i test si utilizzeranno degli strumenti di \underline{benchmark} appropriati in modo da facilitare una misurazione accurata e attendibile delle performance del sistema.
\end{itemize}

\section{Risorse necessarie, risorse disponibili}
Le risorse umane necessarie per eseguire l'attivit\`a di verifica possono variare nel corso delle fasi di sviluppo del progetto in base alla difficolt\`a del processo in corso.\\
Per tutta la durata del progetto i membri del gruppo lavoreranno seguendo le regole prefissate presenti nel documento interno ''Norme di Progetto''.\\
Per tutta la durata del ciclo di vita del progetto \`e compito dell'Amministratore coordinare l'utilizzo delle risorse necessarie alla sua realizzazione.\\
In particolare si prester\`a attenzione per garantire che l'uso delle risorse disponibili sia efficiente per ottenere un adeguato livello di verifica.\\
Per la comunicazione tra i componenti \`e stato creato un account Assembla raggiungibile all'URL: \url{http://www.assembla.com/flows/flow/adg2l2s}. Essendo inoltre ogni componente provvisto di un account Gmail, verr\`a utilizzato il sistema di chat locale per la comunicazione interattiva. Per l'archiviazione dei file verr\`a invece utilizzato un server \underline{Subversion}.

\subsection{Mancanza di un componente}
Nell'ultimo periodo di svolgimento del progetto \`e venuto a mancare il contributo di un componente del gruppo, questo attualmente ha portato ad un ritardo nello svolgimento delle attivit\`a pianificate e una mancanza di una completa verifica. Probabilmente non si sar\`a in grado di coprire completamente il codice finora scritto, inoltre alcune funzionalit\`a opzionali o desiderabili molto probabilmente non saranno implementate. Questo comporta inevitabilmente un abbassamento della qualit\`a generale del prodotto.

\section{Strumenti, tecniche, metodi}
L'attivit\`a di verifica \`e volta a migliorare la qualit\`a dei processi necessari al corretto sviluppo del prodotto; per garantire ci\`o il prodotto e i processi istanziati saranno costantemente sottoposti a questa attivit\`a.\\

\subsection{Verifica del codice}
La verifica del codice verr\`a divisa in due fasi:
\subsubsection{Analisi Statica}
Questa fase verr\`a effettuata durante la stesura del codice sorgente per rilevare errori, omissioni o incongruenze che possono sorgere tra il progetto e i requisiti; questo tipo di analisi sar\`a quindi applicato sulla struttura delle varie componenti del progetto.\\
L'analisi statica comprende le seguenti sottofasi di verifica:
\begin{itemize}
\item \textbf{Analisi del flusso di controllo:} per accertare la corretta esecuzione del codice; si verificher\`a in particolare che non siano presenti istruzioni la cui condizione di accesso non pu\`o mai essere vera (irraggiungibili);
\item \textbf{Analisi del flusso dei dati:} per accertare la corretta inizializzazione dei campi dati e delle variabili nelle istanze dei vari oggetti che compongono il software;
\item \textbf{Verifica formale del codice:} per constatare la correttezza di ogni unit\`a, in modo che la successiva aggregazione delle singole parti produca i risultati attesi.
\end{itemize}

\subsubsection{Analisi Dinamica}
Questa fase prevede la prova di utilizzo del prodotto durante la sua progettazione e al completamento della sua realizzazione per quanto riguarda tutte le sue funzionalit\`a, man mano che queste verranno aggiunte.\\
Pi\`u precisamente l'implementazione di una nuova funzionalit\`a verr\`a preceduta dalla definizione dei test che ne stabiliscono la correttezza. Questo approccio garantisce che il codice prodotto risulti modulare ed i moduli possano essere testati in isolamento gli uni dagli altri.
Gli strumenti per svolgere i test saranno elencati e descritti in questo documento nel momento in cui il gruppo si trover\`a nella necessit\`a di svolgere questo tipo di analisi, quindi indicativamente, come descritto sopra, da quando sar\`a attiva la fase di progettazione. Proprio in questa fase il team dovr\`a prestare particolare attenzione alle tecnologie da usare in modo da facilitare la fase di analisi dinamica. Sar\`a poi compito degli addetti alla fase denominata Realizzazione aderire il pi\`u possibile a quanto deciso in progettazione.
Le diverse tipologie di test sono le seguenti:
\begin{itemize}
	\item \textbf{Test di unit\`a:} ha lo scopo di verificare ogni unit\`a software affinch\`e soddisfi i requisiti previsti mediante l'impiego di un insieme di dati in ingresso;
	\item \textbf{Test di integrazione:} ha lo scopo di verificare la cooperazione tra unit\`a software;
	\item \textbf{Test di sistema:} ha lo scopo di verificare il soddisfacimento dei requisiti di tutto il sistema, in relazione anche all'ambiente di installazione.
\end{itemize}
Sar\`a compito del Verificatore accertarsi della corretta applicazione dei test ed inoltre dovr\`a effettuare un'analisi del codice per evitare un'eccessiva ridondanza e complessit\`a che possano comprometterne l'efficienza.

\subsection{Verifica della documentazione}
L'incaricato alla verifica di ogni documento dovr\`a accertarsi che gli argomenti trattati siano conformi a quanto presente nel Sommario e nella sezione Scopo del documento e che il contenuto di ogni sezione rispetti il titolo assegnato alla stessa.
Inoltre dovr\`a segnalare parti del documento che risultino poco chiare od
ambigue, eliminare porzioni di testo ritenute superflue e privare il documento di ogni errore ortografico, grammaticale o dattilografico.

\subsection{Ambiente di prova e di collaudo}
Con il procedere del progetto si render\`a necessario organizzare degli ambienti di prova e di
collaudo per il software prodotto, per rilevare errori o inconsistenze nei
dati. Nei prossimi rilasci del presente documento ne verranno specificate
le caratteristiche e le funzionalit\`a.

% Capitolo 3 - GESTIONE AMMINISTRATIVA DELLA REVISIONE
\chapter{Gestione amministrativa della revisione}

\section{Anomalie e discrepanze}
Per la gestione di errori durante la realizzazione del prodotto, discostamenti dalle attese e risultati non previsti, il gruppo SevenSoft si \`e imposto di gestire in maniera controllata \underline{anomalie} e \underline{discrepanze}.
\subsection{Modalit\`a di comunicazione}
Per garantire una comunicazione organizzata di anomalie e discrepanze si \`e scelto di assegnare un \underline{ticket} ad ogni prodotto del lavoro del gruppo (documentazione,
codice sorgente, moduli o programmi completi, ecc...) la cui gestione \`e automatizzata da \underline{Assembla}, il sito di appoggio per la realizzazione del progetto.\\
Ogni qualvolta sia completato un \underline{ticket} assegnato ad un prodotto, dovr\`a esserci un corrispondente \underline{ticket} che richieda la verifica del prodotto stesso. Il nuovo \underline{ticket} verr\`a assegnato al responsabile tra i Verificatori attivi, il quale avr\`a il compito di completare la verifica richiesta o, eventualmente, inoltrarlo ad un suo sottoposto.\\
In questo modo si cerca di ottimizzare il tempo necessario alla segnalazione e risoluzione di anomalie e discrepanze del prodotto durante lo sviluppo; inoltre \`e cos\`i possibile tenere traccia di queste, con data di apertura e chiusura di ogni \underline{ticket}.
\subsection{Trattamento delle anomalie}
Eventuali anomalie riscontrate prima della consegna del prodotto al committente sono sotto la responsabilit\`a del gruppo SevenSoft, il quale si impegna a risolverle.\\
Le comunicazioni di anomalie devono contenere le seguenti informazioni:
\begin{itemize}
\item Nominativo del Verificatore o di chi ha riscontrato l'anomalia;
\item Data di creazione;
\item Natura dell'anomalia;
\item Piccola descrizione dello scenario e delle condizioni sotto le quali si \`e verificata l'anomalia.
\end{itemize}
Alla ricezione di una comunicazione di anomalia il Responsabile:
\begin{itemize}
\item Valuta la criticit\`a dell'anomalia indicando (se possibile) il requisito al quale essa \`e associata (cap. 4 del documento ''Analisi dei Requisiti'').
\item Incarica il responsabile tra i Verificatori attivi (in accordo con quanto definito nel Piano di Progetto) per svolgere test sull'anomalia:
\subitem Se dagli accertamenti del Verificatore risulta che l'anomalia \`e banale (ad es. una correzione ortografica in un documento) pu\`o essere risolta direttamente dal Verificatore;
\subitem Se dagli accertamenti del Verificatore risulta che l'errore non esiste, allora il Responsabile avverte chi ha sollevato la comunicazione che la gestione dell'anomalia \`e terminata;
\subitem Se dagli accertamenti del Verificatore risulta che l'errore esiste, la gestione dell'anomalia continua passando ad una seconda fase.
\end{itemize}
La seconda fase per la gestione dell'anomalia continua coinvolgendo il personale addetto alla realizzazione del prodotto intermedio soggetto all'anomalia, allo scopo di valutare la soluzione.\\
Per fare ci\`o il Responsabile, una volta ricevuta la segnalazione, aprir\`a un \underline{ticket} indirizzato all'autore del prodotto testato.\\
Se la soluzione migliore del problema non risulta vantaggiosa in termine di tempo e costi per il committente, o le soluzioni possibili sono tutte in contrasto con il modello di vita del prodotto (sequenziale), viene terminata la gestione dell'anomalia tenendo traccia dell'anomalia irrisolta in un documento che sar\`a corredo del prodotto consegnato. In caso contrario viene eseguita la correzione.\\
Una volta completata la correzione dell'anomalia, il \underline{ticket} corrispondente potr\`a essere chiuso.\\
Questa procedura di controllo e risoluzione sar\`a ripetuta finch\`e il Verificatore non notificher\`a pi\`u anomalie nei suoi test.\\
SevenSoft si impegna comunque a consegnare al committente un prodotto, per quanto possibile, privo di anomalie.

\subsection{Trattamento delle discrepanze}
Qualora le attivit\`a di verifica e validazione provassero l'esistenza di discrepanze in un prodotto semifinale, queste dovranno essere trattate con una procedura simile a quella della gestione delle anomalie (vedi quanto detto sopra).\\
SevenSoft dedicher\`a molto impegno perch\`e le dissonanze vengano portate ad assonanze, in modo che il prodotto finale sia quanto pi\`u possibile adeguato alle aspettative del committente.\\
Qualora la procedura di trattamento delle discrepanze (dallo studio alla attuazione della soluzione) risultasse inaccettabile in termini di tempo e costi per il committente o si presentasse come una situazione di elevato rischio di fallimento del progetto, la discrepanza non verr\`a risolta o verr\`a risolta solo in parte (secondo accordi che vengono presi con il committente stesso in questa situazione).\\
Di ogni discrepanza devono essere documentate alcune caratteristiche:
\begin{itemize}
\item Responsabile/i della discrepanza (se individuabile);
\item Requisito non soddisfatto;
\item Criticit\`a (se la discrepanza \`e totale o parziale);
\item Risorse necessarie per la soluzione (costi, strumenti, ecc.).
\end{itemize}
La procedura di trattamento delle discrepanze, dopo l'apertura del corrispondente \underline{ticket}, \`e equivalente a quella di trattamento delle anomalie.

\section{Procedure di controllo di qualit\`a di processo}
Il controllo della qualit\`a del software interessa l'intero processo di sviluppo del prodotto in questione. A tale scopo sono stati adottati degli standard di documentazione che regolano la struttura e la presentazione dei documenti, nonch\`e degli standard di processo. Quest'ultimi definiscono i processi da seguire durante tutto lo sviluppo software; essi includono definizione dei processi di specifica, progettazione e convalida, oltre ad una descrizione dei documenti che dovrebbero essere scritti durante l'esecuzione di questi processi.\\
Il controllo di qualit\`a prevede il monitoraggio del processo software, per garantire che le procedure e gli standard di qualit\`a siano seguiti. Esso comprende inoltre il miglioramento del processo e la soluzione degli eventuali problemi. Quest'ultimo consiste nel comprendere i processi esistenti e modificarli per aumentare la qualit\`a del software e/o diminuire i costi ed i tempi di sviluppo. Il suo obiettivo principale \`e quello di concentrarsi sul perfezionamento, per migliorare la qualit\`a del prodotto ed in particolare per ridurre il numero di difetti nel software consegnato. Una volta ottenuto ci\`o, gli obiettivi primari diventeranno la riduzione dei costi e dei tempi.\\
Per avere un esteso controllo degli errori, le modifiche apportate ai documenti, in seguito a inconsistenze riscontrate durante la fase di verifica e stesura, verranno notificate secondo alcune convenzioni interne illustrate nel documento ''Norme Di Progetto''. Queste modifiche si troveranno all'inizio di ogni documento nella sezione ''Diario delle modifiche''. I verificatori sono tenuti a controllare parallelamente la documentazione sul lavoro svolto.\\
Molta attenzione di SevenSoft, in questo progetto, \`e focalizzata sull'incremento della qualit\`a dei processi durante la realizzazione del prodotto.\\
Questo intento \`e realizzato gestendo i processi con la tecnica \underline{PDCA} che li rende misurabili, riproducibili e di pi\`u facile verifica. Durante i colloqui interni si parler\`a di qualit\`a del processo, e si tenter\`a di stabilire dei parametri per quantificarla e, possibilmente, migliorarla.\\
La misurazione della qualit\`a di processo avviene:
\begin{itemize}
\item Definendo il processo, specificandone i proprietari, i requisiti e la criticit\`a (gravit\`a delle conseguenze se il processo contiene errori);
\item Esaminando l'output del prodotto, verificando quindi che il prodotto del processo abbia le qualit\`a e caratteristiche attese.
\end{itemize}
Per fare ci\`o \`e necessario innanzitutto definire quali sono le caratteristiche di qualit\`a del processo, per poi eseguire un'attivit\`a di verifica documentata per vedere se tali caratteristiche sono soddisfatte.\\
Da questi parametri \`e possibile avere una misura per decidere se le risorse messe a disposizione del processo erano maggiori o minori di quelle necessarie e, nel caso che il prodotto del processo non avesse le caratteristiche di qualit\`a aspettate, si avranno dei parametri per valutare l'onere dovuto al miglioramento del prodotto del processo (in termini di tempo, risorse e costo).\\
L'Amministratore ha il compito di redigere delle norme per far s\`i che il prodotto del processo sia facilmente analizzabile e verificabile (strutturato, predicibile, modulare, chiaro e non ambiguo nei contenuti).

\section{Metriche sulla copertura dei test sul codice}
Durante l'implementazione da parte del Programmatore delle funzionalit\`a
richieste dai test, \`e possibile che venga aggiunto del codice che non verr\`a mai testato.\\
Sar\`a compito del Verificatore controllare attraverso gli strumenti messi a disposizione che la percentuale del codice coperto si avvicini il pi\`u possibile a 100 prima della consegna del prodotto. Per questo scopo il team sfrutter\`a la possibilit\`a di creare automaticamente le classi di test che permetteranno quindi di avere una certa sicurezza di ci\`o che è stato testato. In questo modo si dovranno andare a controllare solo le eventuali modifiche apportate.

\subsection{Emma}
Sono disponibili strumenti automatici che calcolano la copertura dei test sul codice.
NetBeans dispone di un plug-in basato su Emma. Emma \`e uno strumento che permette di definire la copertura dei test, verr\`a utilizzato per controllare quanto codice \`e stato coperto, cercando di coprirne il pi\`u possibile.

% Capitolo 4 - RESOCONTO DELLE ATTIVITA DI VERIFICA
\chapter{Resoconto delle attivit\`a di verifica}

\section{Tracciamento componenti-requisiti}
Per una completa e chiara tracciabilit\`a componenti-requisiti, ogni componente, classe o metodo del prodotto SiFiSy \`e stato ideato come risposta ad ogni singolo requisito. Al fine di tenere traccia di tali corrispondenze \`e stata redatta una tabella, consultabile nel documento \textit{Specifica Tecnica}, che identifica per ogni componente quali sono i requisiti che la interessano. Ci\`o faciliter\`a la fase di verifica; si attester\`a quindi se ogni componente soddisfi pienamente i requisiti ad esso associato.

\section{Dettaglio dell'esito delle revisioni}
Tutta la documentazione prodotta per essere consegnata alle revisioni \`e accuratamente controllata dal Verificatore di turno.\\
L'analisi statica effettuata su questi documenti si basa principalmente sull'accertarsi che le regole elencate nelle \textit{Norme di Progetto} siano perfettamente rispettate, che non siano presenti errori grammaticali, che il testo sia scorrevole e di facile comprensione per il lettore e, infine, che non siano presenti errori di impaginazione o altri problemi che complichino la consultazione della documentazione.
\subsection{RR - Revisione dei Requisiti}
Documentazione per la Revisione dei Requisiti: segnalati alcuni errori di tipografia e ortografia corretti celermente dai rispettivi redattori. Lacune o errori sulla stesura di alcune sezioni dei documenti come riferimenti bibliografici troppo generici o utilizzo scorretto dei nomi.\\
I documenti da rivedere e correggere in maniera approfondita sono soprattutto quello di \textit{Analisi dei Requisiti}, \textit{Norme di Progetto} e \textit{Piano di Qualifica}.

\subsection{RPP - Revisione di Progetto Preliminare}
Documentazione per la Revisione Preliminare di Progetto: segnalati alcuni errori tipografici e soprattutto di spaziatura. Consiglio di riorganizzare la struttura del Diario delle modifiche dei documenti. Gravi lacune sul documento denominato \textit{Specifica Tecnica}, alcune imprecisioni pi\`u o meno sostanziali nei documenti \textit{Piano di Progetto} e \textit{Piano di Qualifica}. Mancata consegna del documento \textit{Norme di Progetto}.
Il team nota un miglioramento, anche se non di grande entit\`a, su alcuni documenti anche se il risultato non pu\`o essere ritenuto soddisfacente. Il team riscontra difficolt\`a nella redazione dei documenti per cui cercher\`a di migliorare questo aspetto. L'impiego di un correttore ortografico automatico pu\`o facilitare il compito del team.
Verr\`a riconsegnato il documento \textit{Specifica Tecnica} in quanto ritenuto insufficiente.

\subsection{RPD - Revisione di Progetto Definitivo}
Il team non ha sostenuto la Revisione di Progetto Definitiva ma ha dovuto riconsegnare il documento denominato \textit{Specifica Tecnica}. Il documento resta insufficiente anche se con qualche miglioramento. Verr\`a verificato nuovamente il documento per tentare il miglioramento non ancora effettuato. Restano lacune evidenti sulla stasura dei documenti da parte del team.

\section{Dettaglio delle verifiche tramite test}
Per l'esecuzione delle attivit\`a di verifica tramite test verranno utilizzati i
moduli e le classi rese disponibili da Java all'interno dell'ambiente di sviluppo NetBeans IDE 6.8, ad esempio per i test di unit\`a saranno a disposizione le classi JUnit.
La fase di test \`e generalmente onerosa e laboriosa, attraverso gli strumenti resi disponibili il Verificatore ha la possibilit\`a di creare automaticamente del codice per testare la classe in oggetto. Il codice, opportunamento modificato in base alle esigenze stesse del test in questione, inizialmente si occupa di passare ai metodi delle componenti da testare degli opportuni parametri (alcuni errati ed altri corretti secondo gli input dei test case), confrontando poi l'output prodotto con quello atteso. Alcuni test \`e necessario eseguirli a mano, come ad esempio i test riguardanti la componente gui, tali test sono comunque una parte minima di tutti i test da eseguire e non incidono eccessivamente sul costo dell'intera fase di test.
Infine ricordiamo che i test hanno come scopo l'individuazione di difetti o errori. Per questo un test che non restituisce in output nessun tipo di problema \`e da considerarsi negativo.

\subsection{Unit Test}
Come gi\`a detto le classi Junit serviranno per fare test di unit\`a. Ogni classe prodotta avr\`a la sua classe di test che avr\`a lo stesso nome della classe seguita dalla parola \textsf{Test}. Quindi la classe \textsf{Simulation} avr\`a come sua classe di test \textsf{SimulationTest}. Ogni metodo avr\`a il suo relativo metodo di test che avr\`a lo stesso nome del metodo preceduto dalla parola \textsf{test}, ad esempio \textsf{testCalculateBlockNumber()}.\\
Un esempio di test di unit\`a \`e data dalla seguente porzione di codice:
\begin{verbatim}
public void testCalculateBlockNumber(){
        test.setBlockDimension(1);
        test.setBlockExponent(10);
        test.setPartitionDimension(10);
        test.setPartitionExponent(30);
        result=test.calculateBlockNumber();
        assertEquals(
                "Dovrebbe ritornare 2Mb cioè 10485760 blocchi",10485760,result);
        
        test.setBlockDimension(5);
        test.setBlockExponent(10);
        test.setPartitionDimension(7);
        test.setPartitionExponent(30);
        result=test.calculateBlockNumber();
        assertEquals(
                "Dovrebbe ritornare 2Mb cioè 1468006 blocchi",1468006,result);
}
\end{verbatim}

\subsection{Regression Test}

Il test di regressione va eseguito ogni volta che viene modificata l'implementazione di una funzionalit\'a. A tale scopo, \'e possibile eseguire nuovamente i test esistenti sul codice modificato per stabilire se le modifiche apportate hanno alterato elementi precedentemente funzionanti. Se necessario il team valuter\'a la possibilit\'a di scrivere nuovi test per maggiori controlli con lo scopo di aumentare la qualit\'a generale del prodotto e di garantire un'adeguata copertura; tuttavia, per non compromettere e rallentare eccessivamente la realizzazione del prodotto, sono da evitare cospicue perdite di tempo in questo tipo ti test.


\subsection{Copertura dei test sul codice}
Come descritto precedentemente sar\`a  utilizzato uno strumento messo a disposizione da NetBeans per misurare la copertura dei test sul codice.  L'attuale situazione di copertura dei test sul codice \`e riportato nel file \textit{coverage.pdf} allegato al presente documento.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%				FINE DEL DOCUMENTO (NON MODIFICARE)						%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}															%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 